Subject: Session Services Split

From: "Roy Brabson (254-7332 (T/L 444))" <[email-masked]>
Date: Thu, 15 Sep 94 11:04:17 EDT

Well, John successfully shamed me into appending a description of the
proposed SS split.  It includes a brief description of the various
functions placed in each of the two new components.  No flows are
included, but there really isn't a need to modify the existing flows
much to implement this change.

SS COMPONENT SPLIT
__________________

OVERVIEW OF THE FUNCTION SPLIT
______________________________

Within the APPN architecture reference model, Session Services (SS) has two
primary responsibilities.  First, SS assists in LU-LU session initiation and
termination.  Second, SS activates, deactivates, and maintains CP-CP sessions
between APPN nodes.

This document contains a proposal to separate the CP-CP session activation
functions from the LU-LU session activation functions, as the two primary
responsibilities of SS are quite disjoint with virtually no overlap.  This
split will accomplished by creating two distinct components.  The first,
CP-CP Session Services (SSC), will be responsible for the CP-CP session main-
tenance.  The second, LU-LU Session Services (SSL), will be responsible for
assisting in LU-LU session initiation and termination.

RATIONALE FOR SPLITTING THE COMPONENT
_____________________________________

The primary purpose for splitting SS into two components is to simplify main-
tenance.  CP-CP session activation is a relatively stable function, likely to
require few if any changes as future enhancements are made to the APPN
control point.  On the other hand, LU-LU session activation tends to require
modifications as new APPN control point functions are added.  As stated pre-
viously, the two functions have little to no overlap in processing.

POSSIBLE FUTURE SPLITS
______________________

In the future, it may be desirable to remove the FQPCID generation from the
SS component.  Currently, SS is responsible for the generation of FQPCIDs.
It receives ASSIGN_PCID signals from other components, such as Session
Manager, Management Services, and Session Connector Manager, and returns the
assigned FQPCID in the ASSIGN_PCID_RSP signal.  Since the generation of
FQPCIDs is algorithmic in nature, a more optimal approach would be to use a
function call to generate FQPCIDs versus the signal interface.

COMPONENT OVERVIEW FOR CP-CP SESSION SERVICES
_____________________________________________

PURPOSE OF CP-CP SESSION SERVICES
_________________________________

CP-CP Session Services (SSC) is the component in the APPN Control Point (CP)
responsible for managing the activation and deactivation of CP-CP sessions
between adjacent nodes.  APPN Control Points establish CP-CP sessions with
other APPN Control Points in order to create a contiguous APPN network.

CP-CP sessions between two adjacent APPN nodes are actually two half-duplex
sessions, a conwinner session and a conloser session.  Together, the two ses-
sions simulate a full-duplex session.  Each APPN node sends data to an adja-
cent node on its conwinner session and receives data on its conloser session.

FUNCTIONS PROVIDED BY CP-CP SESSION SERVICES
____________________________________________

SSC provides the following services:

CP-CP SESSION ACTIVATION

SSC manages the activation of both the conwinner and conloser halves of the
CP-CP session pair.  When the partner node initiates the activation of CP-CP
sessions, SSC waits for the receipt of the CP_CAPABILITIES GDS variable from
the partner node before initiating its contention winner CP-CP session
session.  SSC does not attempt to activate its contention winner CP-CP
session session when a BIND is received with the CPSVCMG class-of-service.

Triggering CP-CP Session Activation

Given that a connection supporting CP-CP session exists, CP-CP sessions are
automatically triggered by any of the following:

o   The activation of a connection to an adjacent APPN node with which CP-CP
    sessions are not already active.

o   The failure of an existing CP-CP session.  Certain types of session fail-
    ures cause SSC to redrive session activation.

o   CP-CAPABILITIES are received from an adjacent APPN node.

    +--- NOTE TO IMPLEMENTERS ----------------------------------------------+
    |                                                                       |
    | The APPN architecture actually states that CP-CP sessions are sup-    |
    | posed to be initiated when a BIND for a CP-CP session is received     |
    | from an adjacent APPN node.  However, we have found it simpler to     |
    | instead wait for the CP_CAPABILITES GDS variable which will follow.   |
    |                                                                       |
    +-----------------------------------------------------------------------+

VALIDATION OF CP-CP SESSION ACTIVATION REQUESTS

SSC decides whether or not to accept or reject a CP-CP session request.  The
request for a session must satisfy the following requirements:

o   The session cannot be between two NNs with different NETIDs.
o   The session cannot be between two ENs.
o   An EN can have CP-CP sessions with at most one NN at any time.

CP-CP SESSION DEACTIVATION

SSC manages the deactivation of both the conwinner and conloser halves of the
CP-CP session pair when necessitated by either operator intervention, link or
node deactivation,or errors in the network.

There is no change from the existing logic described in the APPN architecture
reference.  However, SSC may now receive a deactivation request from SSL for
protocol violations.  SSC should deactivate the CP-CP sessions when this
request is received.

NOTIFICATION OF ADJACENT CP CONNECTIVITY

SSC notifies other APPN components, such as Directory Services (DS), when
CP-CP sessions are activated or deactivated with an adjacent CP.  There is no
change from the existing logic described in the APPN architecture reference.

NETWORK NODE SERVER SELECTION AT AN END NODE

At an APPN End Node (EN), SSC is responsible for the selection of an adjacent
Network Node (NN) to serve as the ENs Network Node Server (NNS).  In the EN,
SSC must make sure that the EN has a current, active NNS.

There is no change from the existing logic described in the APPN architecture
reference.

AUTHORIZATION VERIFICATION OF DOMAIN ENS

At an APPN NN, SSC is responsible for verifying that a domain APPN EN is
authorized or not authorized.

OWNERSHIP OF SERVICE TRANSACTION PROGRAMS

SSC will retain ownership of the existing SS service transaction programs.
These are:

o   CP_CAP_SON_TP
o   REQUEST_CP_CAP_TP
o   DEACT_SESSION_TP

COMPONENT OVERVIEW FOR LU-LU SESSION SERVICES
_____________________________________________

PURPOSE OF LU-LU SESSION SERVICES
_________________________________

LU-LU Session Services (SSL) is the component of the APPN Control Point (CP)
responsible for managing the activation and deactivation of LU-LU sessions
between two resources.

FUNCTIONS PROVIDED BY LU-LU SESSION SERVICES
____________________________________________

LU-LU SESSION INITIATION

SSL processes session initiation requests received from other components
within the APPN control point or from other APPN nodes.  This includes:

o   Processing a INIT_SIGNAL or a CD-Initiate request received on a
    LOCATE_MESSAGE from DS

o   Performing Mode-to-COS mapping, if required.

o   Initiating a directory search to locate the destination resource.

o   Performing route computation to the destination resource at the NN(OLU).

o   Activating the next hop in the session route, if necessary.

LU-LU SESSION TERMINATION

When an LU-LU session is terminated, SSL will receive notification.  At the
CP(OLU) or CP(DLU), SSL will receive a SESSEND_SIGNAL from Session Manager.
At an intermediate node, SSL will receive an ISR_SESSEND from Session Con-
nector Manager.

BIND PROCESSING BY INTERMEDIATE NETWORK NODES

Discussion on BIND processing

When a BIND is received at an intermediate node, SSL will recerive an
ISR_INIT signal from Session Connector Manager.  SSL performs the following
functions as part of BIND processing:

o   Processing the ISR_INIT signal from SCM.  The ISR_INIT signal may or may
    not have a session RSCV.

o   If the ISR_INIT signal does not have a session RSCV, then SSL will ini-
    tiate a directory search and perform route computation as described under
    "LU-LU Session Initiation".

o   Performing Mode-to-COS mapping, if required

o   Activating the  next hop in the session route, if necessary.

ACTIVE-SESSION COUNT MONITORING

SSL is responsible for maintaining the active session count on a per-
Transmission Group (TG) basis.  SSL increments the count of active sessions
when it receives a SESSST_SIGNAL from Session Manager, sends a CINIT_SIGNAL
to Session Manager, or sends a sends an ISR_CINIT signal to Session Connector
Manager.  SSL decrements the count when it receives a SESSEND_SIGNAL or an
ISR_SESSEND signal.  When the active session count for a TG reaches zero, SSL
notifies Configuration Services (CS).

FQPCID GENERATION

SSL is responsible for processing requests for the assignment of an FQPCID.
Other components request SSL assign an FQPCID by sending the ASSIGN_PCID
signal to SSL.